Fixes microsoft#8306.
## Summary
Building DXC with newer Apple toolchains fails in
`include/llvm/ADT/StringRef.h` because libc++ now rejects user
specializations of certain standard library traits. DXC currently
specializes:
- `std::is_nothrow_constructible<std::string, llvm::StringRef>`
- `std::is_nothrow_constructible<std::string, llvm::StringRef &>`
- `std::is_nothrow_constructible<std::string, const llvm::StringRef &>`
On Xcode 26.4 / Apple clang 21 / libc++, that now produces an error
like:
> `is_nothrow_constructible` cannot be specialized: Users are not
allowed to specialize this standard library entity
## What this changes
This patch keeps the existing HLSL workaround for non-libc++ standard
libraries, but disables those `std::is_nothrow_constructible`
specializations when building against libc++:
```cpp
#if !defined(_LIBCPP_VERSION)
...
#endif
```
Why this fixes the issue
The failure is caused by the specializations themselves, not by any
runtime behavior in StringRef.
For libc++:
- the specializations are now ill-formed and rejected at parse time
- libc++ already computes std::is_nothrow_constructible<std::string,
llvm::StringRef> correctly without the workaround
So the fix is to stop declaring the forbidden specialization on libc++,
while preserving the existing behavior everywhere else.
Why I chose this approach
I looked at the HLSL-specific block in StringRef.h and tested the
current Apple libc++ behavior directly. Without the manual
specialization, libc++ still reports the relevant
is_nothrow_constructible cases as false, which matches the intent of the
original workaround.
That made this the narrowest safe fix:
- it resolves the Xcode/libc++ build break in microsoft#8306
- it does not change runtime code generation or ABI
- it preserves the original workaround for non-libc++ environments where
it may still be needed
Validation
I verified:
- the original header fails to compile with current Xcode/libc++
- after this change, the header compiles cleanly
- on libc++, the relevant std::is_nothrow_constructible instantiations
still evaluate to false

(cherry picked from commit bacbfaa)

Fixes microsoft#8306.
## Summary
Building DXC with newer Apple toolchains fails in
`include/llvm/ADT/StringRef.h` because libc++ now rejects user
specializations of certain standard library traits. DXC currently
specializes:
- `std::is_nothrow_constructible<std::string, llvm::StringRef>`
- `std::is_nothrow_constructible<std::string, llvm::StringRef &>`
- `std::is_nothrow_constructible<std::string, const llvm::StringRef &>`
On Xcode 26.4 / Apple clang 21 / libc++, that now produces an error
like:
> `is_nothrow_constructible` cannot be specialized: Users are not
allowed to specialize this standard library entity
## What this changes
This patch keeps the existing HLSL workaround for non-libc++ standard
libraries, but disables those `std::is_nothrow_constructible`
specializations when building against libc++:
```cpp
#if !defined(_LIBCPP_VERSION)
...
#endif
```
Why this fixes the issue
The failure is caused by the specializations themselves, not by any
runtime behavior in StringRef.
For libc++:
- the specializations are now ill-formed and rejected at parse time
- libc++ already computes std::is_nothrow_constructible<std::string,
llvm::StringRef> correctly without the workaround
So the fix is to stop declaring the forbidden specialization on libc++,
while preserving the existing behavior everywhere else.
Why I chose this approach
I looked at the HLSL-specific block in StringRef.h and tested the
current Apple libc++ behavior directly. Without the manual
specialization, libc++ still reports the relevant
is_nothrow_constructible cases as false, which matches the intent of the
original workaround.
That made this the narrowest safe fix:
- it resolves the Xcode/libc++ build break in microsoft#8306
- it does not change runtime code generation or ABI
- it preserves the original workaround for non-libc++ environments where
it may still be needed
Validation
I verified:
- the original header fails to compile with current Xcode/libc++
- after this change, the header compiles cleanly
- on libc++, the relevant std::is_nothrow_constructible instantiations
still evaluate to false

(cherry picked from commit bacbfaa)